Solved: In practice, how do you handle errors?

This is similar to an issue I was working on, but they changed my priorities on me again...

What I've come up with is that that:

1. When using the database toolkit the errors are VERY VERY delayed.

2. Some of the VIs in the toolkit wouldn't even output their errors until I put a simple error handler on the error cluster output. (I have no idea what that was all about. Tech support said, "That is odd." Yep, I agree...

3. I use a Functional global to pass data throughout the program.

I have been experimenting with a case structure in a separate loop. In this case structure I have the following cases:

Connect - Loop until connection is made. If connection takes too long go to error case

Read or Write data - Do required function, loop back to this case, or on error go to error case.

Error - This is pretty complex. I ping for connection to required items to perform ANY or ALL of the needed error functions. Restart a system or systems, log to SQL table, Email users from the correct users in all user groups selected from a database table, local alarming at the system in the factory, log alarm to local log file, handle undone error functions when the correct system is reconnected and can be pinged again, write an error to a database table (This table is monitored by computers around the factory. These computers will alarm to notify people of the problem. This program also allows them to select to go to a responsive help website I've created on both the industrial and office intranets. This website opens with the exact help they need within the LabView alarm monitoring program by use of an html5 accordion. I find this type of a help system to be best as I can easily modify it to change as needed. Our personnel tend to need exact step by step instructions with pictures for the things that come up on the computer and automation systems. Then they can follow the steps needed to correct the problem.

Disconnect - This will probably end up in the Error case eventually, but it currently disconnects from the database and sends things on to the connect case.

My eventual plan is to use the Error handling routine I'm developing in this case structure as reusable code that can be dropped in as a VI and easily configured for any needed use. I also want to add in functionality for text messaging to certain groups of users listed in the SQL database. I've found that using a simple error case structure isn't good enough to handle many of the things that I run into, but I do use this, as shown in the SixClear and NI training videos when it is appropriate. Honestly I've never found a need for the simple error handler to actually pop up for the user outside of when I'm debugging code.

My goal is to keep things running in the factory whenever possible. In order to do this I have to look at what can be done to automatically restart connections, computers, PLCs, etc... whenever possible. Many of the people in the factory won't even look at an alarm. This forces me to alarm in multiple places to get someone to actually do anything about it. I actually have it set up to email me at my personal email if a problem isn't dealt with for too long. Then I can VPN into the factory networks and see what needs to be done... It's a bit exasperating at times, but this is the ocean that I get to continually tread water in... Hopefully you won't have to go to the depths that I need to in your facility, but some of these kinds of functions are most likely useful in a lot of other cases.